1. Technical Field
The present invention relates to an improved data processing system. In particular, the present invention relates to implementing enterprise JavaBeans™ development environment in a data processing system. Still more particularly, the present invention relates to implementing container managed uses, ownerships, reference only, batch processing, and sequential stream relationships in an enterprise JavaBeans™ development environment.
2. Description of Related Art
In most enterprise application development environments, developers often use enterprise JavaBeans™ objects for modeling interactions between components and for managing data persistence in their applications. J2EE Enterprise JavaBeans™ is a specification available from Sun Microsystems, Inc. Examples of enterprise JavaBeans™ (EJB) objects include ‘Entity’ beans and ‘Session’ beans. Entity beans model the persistent data used by the EJB application and application clients. An Entity bean is a type of enterprise JavaBeans™ that persists data in a data source beyond the lifetime of the client application. Session beans are designed to encapsulate the functions of a given task (or session) as requested by clients of the EJB interfaces. Often Session beans themselves are used to interact with the modeled Entity beans to perform some business logic.
Currently, relationships between entity beans in an enterprise application may be maintained by using container managed relationship (CMR) fields. Developers implement CMR fields by specifying the desired relationship between entity beans in the entity bean definition and adding the EJB relationships to a deployment descriptor file. When the enterprise application is deployed, the EJB container automatically enforces referential integrity of the relationships. Thus, when the code of an entity bean is updated, the container automatically updates the related entity bean. In this way, business methods may use CMR accessor methods to manipulate container managed relationships.
While relationships between entity beans are maintained, there is no existing mechanism that represents ‘uses’ relationship between an entity bean and a session bean. Thus, if an entity bean uses a session bean that encapsulates a related but reusable task, developers have to manually perform a lookup of a session bean home interface using Java Native Directory Interface (JNDI) passing a name made available to the entity bean code and then create an instance of the session bean. The container does not manage the relationship or generate relevant code. This manual operation of session bean lookup can be error prone, time-consuming, and inconsistent with the manner in which other container managed relationships are handled. Therefore, it would be advantageous to have an improved method for the container to maintain a ‘uses’ relationship between enterprise JavaBeans™, particularly between entity and session beans, such that implementation of JavaBeans™ may be more simple and more consistent.
In addition to uses relationship, there is also no existing mechanism that represents an ‘owns’ relationship between entity beans. Ownership is a particular type of directional relationship that indicates all access to the target entity of the relationship is implied to pass through the source entity. Thus, the “key” of the target always includes the key of the source. For example, if an order entity bean with an order number as the key “owns” a number of line items, the implicit key of an order line item is the order number plus any other properties of line items that ensure uniqueness, such as the product key or a sequence number.
Currently, an entity definition must explicitly specify the key fields of the owner entity as well the others specific to the target owned entity that insure uniqueness in any context. The disadvantage of this approach is that the owned entity is only usable in the limited context of the ownership relationship that exists at the moment. But that relationship may change. For example, if the developer subsequently decides that an order entity is owned by a customer entity, then the order entity needs to be changed to include the customer key fields as part of its essential state. Because the ownership relationship propagates to all other entities owned by order, the line item entity needs to be modified to include the customer key fields as part of its essential state as well.
Therefore, it would be advantageous to allow a developer to specify only the “key” properties of an entity and assume that when a container managed “ownership” or “owns” relationship is specified between two entities, that the key of the “owner” is propagated to the “owned” entity for purposes of deployment to the underlying database technology. Such an approach will enable an entity definition to be reused in many contexts without changes to the basic “type” definition.
For example, the same line item entity could be used in orders whether owned by customers or not. Further, an entity like an Address could be owned by multiple types of entities simultaneously and even more than once by the same one (such as a shipping and billing address for a customer). Such a mechanism enables all persistent objects to be declared as entity EJBs, with the understanding that the “owns” relationship will make the distinction between deployment options.
With CMR fields, if a relationship is established between entity beans, a method is generated to reference an entity bean from another entity bean. In cases of a one-to-many relationship, the entity bean on one side retrieves a list of related entity beans using the method. Currently, in order to extract primary key values from the list of entity beans returned, developers have to manually write additional code to extract the values. This manual process is costly, since the non-key essential state of the entity (the CMP fields) is typically needed to instantiate the EJB in memory. Furthermore, a getPrimaryKey method has to be invoked on the objects. In addition, this manual process is redundant because the container already has access to the key values when the list is built. Therefore, it would also be advantageous to have an improved method that enables automatically generating a method that performs the manual process to return a list of simple primary key values instead of the list of entity EJBs.
Furthermore, in current J2EE application servers, there is no existing mechanism that supports efficient batch computations. Batch computations are operations that execute highly repetitive tasks according to a preconfigured schedule. For example, a “transfer funds” batch process in a banking application may be needed to repeatedly transfer funds from one account to another as specified by an input file or database that contains the from and to account numbers, along with the amount to transfer. Other examples of batch computations include cases where the account has insufficient funds, a request is then written to an “overdraft” output file, where a final summary record is logged describing the number of funds transferred and total amount of funds transferred successfully as well as the number and total amount of overdrafts.
Typically, an enterprise batch job is scheduled manually by a user using non J2EE solutions. However, the non J2EE solutions do not allow reuse of online J2EE application logic, such as transferring funds from one account to another. Thus, a user has to re-implement the online application logic every time a batch job is run by the non J2EE solutions.
Further, enabling many of the expected qualities of service, such as the ability to checkpoint and restart, requires manual coding to persist the “essential state” of the batch job. Making the checkpoint interval configurable also requires manual coding. In case of a fund transfer batch process, the essential states include the position in the transfer request file, the current sum of funds transferred successfully, and the total number of accounts involved. Requiring manual coding of this restart logic is likewise tedious and error prone.
Therefore, it would be advantageous to have an improved method to support batch computations in J2EE application servers, such that batch applications may be built, deployed, and run in a J2EE environment enabling reuse of application logic.
In addition, even though CMR fields allow establishing multi-cardinality relationships between two entities, the assumption is that a list is returned including all the related entities. There is no existing mechanism for specifying that the multi-cardinality relationship is primarily “one at a time” for the purpose of either reading or writing. This relationship is known as a “streaming” relationship. A fund transfer batch job is one example where a streaming relationship between two entities is especially important. The fund transfer batch job may require reading one fund transfer request at a time or writing one overdraft record at a time.
Typically, because the batch data is associated with file data streams, the code for reading records is manually coded in a non-standard way that prevents the container from managing the efficiency or establishing relationships with other EJBs. Even if such a streaming relationship is coded with standard entity EJBs, the developer must manually code and use a special kind of finder method that returns a single entity when given a current position, possibly among others, for propagation of keys.
Therefore, it would be advantageous to have an improved method that recognizes a relationship between entity beans as an input or output data streaming relationship, such that relevant code may be automatically generated to manage the relationship. In addition, it would be advantageous to have an improved method that automatically generates a method for input stream relationships that returns the last record in the data stream, such that no explicit lookup is necessary in the source code; and a method for output stream relationships that appends a record to the end of the stream.
Furthermore, for batch processing in a J2EE environment, there is no existing mechanism that provides a generic definition for batch processing, including job steps and other configuration information for a batch job. Currently, developers have to customize each batch job step separately, which requires significant development effort. Therefore, it would be advantageous to have a definition language integrated with the EJB container that allows developers to specify batch processing information.